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[57] ABSTRACT 

A computerized system offers a uniform platform for con- 
ducting electronic transactions in multiple different environ- 
ments. The system includes a portable, multi-purpose, inte- 
grated circuit (IC) card and complimentary computer 
software which enables access and management of resources 
maintained on the IC card. The software runs on a user's 
personal computer, empowering the user to initialize the IC 
card, configure the card with the resources that the user 
wants' to maintain on the card, and to manage those 
resources. The software enables the user to generate private/ 
public key pairs and establish or change passcodes for 
access to the card resources. The IC card itself provides the 
electronic vehicle for securely transporting the user's private 
keys and certificates without exposing them in plaintext 
form. The IC card is designed with enough processing 
capabilities to perform rudimentary cryptographic functions 
so that the private keys may be employed for signing or 
encryption without ever being released from the card. 

53 Claims, 12 Drawing Sheets 
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SYSTEM AND METHOD FOR 
CONFIGURING AND MANAGING 
RESOURCES ON A MULTI-PURPOSE 
INTEGRATED CIRCUIT CARD USING A 
PERSONAL COMPUTER 

TECHNICAL FIELD 

This invention relates to integrated circuit (IC) cards, such 
as smart cards, PC cards, and the like, which are capable of 

being used for multiple different applications. This invention lo this confidential code name. Once validated, the user is free 

further relates to systems and methods for initializing, to roam the computer and network for resources and ser- 

configuring, and managing various resources maintained on vices. Unfortunately, the password authentication process 

the IC cards. This invention also relates to the secure often falls short of providing adequate security or user 

management and transportation of cryptographic-related authentication. The password protocol, by itself, is well 

resources, such as keys and certificates, from one location to 15 known to be weak and conducive to successful illegitimate 

another, attacks. 



ity are becoming more important as reliance on computer 
networks increases. In modem network environments, iden- 
tification and authentication are commonly used in access 
protocols aimed at preventing unauthorized users from gain- 
ing access to resources and services provided by the net- 
work. Typically, a user identifies himself or herself to a 
computer using a login dialog in which the user enters a 
descriptive and secret code name. The authentication pro- 
cess running on the computer validates the user based upon 



BACKGROUND OF THE INVENTION 

Computers are playing an ever increasing role in day-to- 
day personal management. Individual users keep appoint- 
ment schedules, track bank and credit card accounts, manage 
investment portfolios, reserve travel accommodations, trans- 
act business, order products, and submit payment all elec- 
tronically from their own computers, Tliis revolution is 
being spawned by the combined phenomenon of rapid and 
wide deployment of personal computers in both business 
and home environments, explosive growth in interconnect- 
ing these personal computers to networks and online 
services, and dramatic increase in the deployment of retail 
terminals or kiosks based on PC technology. 

As part of this trend, businesses have identified significant 
opportunities for electronic commerce, not only with other 
businesses, but also through direct access to the consumer. 
Merchants are selling wares in an electronic marketplace 
which enable users to shop and purchase goods using their 
computer. For instance, many merchants are developing web 
sites that allow users to browse products over the Internet. 
Payment and settlement following any purchase are likewise 
handled electronically among the merchants, their banks, 
any credit companies, and the purchasers* banks. 

One consequence of this revolution is a growing demand 
for high data security and for high assurance in user iden- 
tification and authentication. In an electronic marketplace, 
there is no face-to-faoe transaction in which security is 
ensured by the presence of both parties and authentication of 
the consumer involves personal recognition or quick veri- 
fication of a corroborating piece of identification (i.e., a 
credit card or a driver^s license). Rather, in an electronic 
arena, the consumer might live in one state or country, while 
the merchant resides in another, and the two parties never 
meet in person. 

For an electronic marketplace to flourish, consumers and 
merchants must believe that information being exchanged 
between them is secure. They must also trust that the other 
party is legitimate. Moreover, each party must also have 
some assurance that the information received from the other 
party did in fact originate at the other party (and not an 
impostor) and that the information has not been subse- 
quently altered or tampered with by an intruder. 
Accordingly, security, identification, authentication, and 
information validity are important to the full development 
and acceptance of an electronic marketplace. Furthermore, 
these capabilities must be readily portable by the end user in 
a manner which facilitates access to the electronic market- 
place from a variety of locations. 

Even outside of the commerce environment, the same 
themes of security, identification, authentication, and valid- 
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The problems inherent in password approaches has given 
rise to a variety of products which perform user authenti- 
cation. Such products typically employ cryptographic tech- 
20 nology in combination with hardware token devices. These 
token devices are typically pre-configured by the manufac- 
turer and dehvered to the user and replace the login pass- 
word with a more robust and difiScult to attack challenge - 
response protocol. While this technology is adequate for 
access control on an enterprise network (i.e., a local network 
for a business or other entity), it is not particularly scalable 
to public networks used by a large user population. This is 
the resuh of reliance on a centralized access control server 
which has knowledge of all the tokens issued to valid users. 

Another problem which existing hardware tokens has 
been generation and management of key values. "Keys'* are 
a numerical value, often expressed digitally as a number of 
bits, which are used in cryptographic algorithms that encrypt 
and decrypt messages. The keys are uniquely associated 
with a particular identity, such as a user or a computer. 
Configuring milhons of devices, each with its own unique 
keys, would be a huge processing task for the manufacturer, 
resulting in a significant increase in the cost of the hardware 
device. From a security standpoint, another problem is that 
the manufacturer becomes a centralized point of attack in 
which bandits can covertly attempt to steal private key 
information. Another problem concerns replacement of 
keys. Once a key has exhausted it useful life, the manufac- 
turer must either issue new devices with new keys or 
reconfigure old devices to change the keys. Once again, this 
is an extremely difficult, expensive, and inefficient task in a 
large scale system. 

Accordingly, there is a need to develop an open identifi- 
cation and authentication architecture that does not rely on 
proprietary or customized hardware devices. 

In addition to identification and authentication, the elec- 
tronic arena also requires secure data transmission over an 
insecure public network (e.g., the Internet). Cryptography 
55 has evolved in the electronic setting as a means to securely 
transfer information over a communication system that is 
presumed to be insecure. Cryptography provides the neces- 
sary tools to digitally secure sensitive is and valuable 
electronic messages in a manner that insures privacy 
60 between the sender and recipient of the communique, even 
though the message is subject to interception on the insecure 
communication system. 

Through use of both public key (or asymmetric key) 
cryptography combined with secret key (or symmetric key) 
65 cryptography it is possible lo address the above require- 
ments. To initiate a secure electronic transaction between 
two individuals, one can use an authentication protocol 
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based on public key cryptography. This protocol will result "Bsafe libraries" by RSA Data Security Inc., "X/Open 

in the exchange of public key certificates aad data encrypted CAPI", and "PKCS#'*. However, each of these systems 

with a private authentication key between the two users. The permit direct access of the application to the keying material, 

certificates contain a party's identification, the party's public There is no protection of these cryptographic resources from 

keys (typically both a authentication or signature key and a 5 electronic attack. Furthermore, the Bsafe system, which is 

key exchange key will be used), and is digitally signed by a t^e most widely used cryptography system, directly attaches 

trusted certifying authority. Upon receipt of the certificate, the cryptographic code to the application. There is no 

each party validates the certifying authority's signature contemplation of protecting the keys from ignorant or mah- 

(using their pubhcly available key . They can then use the ^^^^ ^^^^^^ ^^^^^ ^^^^^^ appUcations. 

public key m the certificate to vahdate the authentication , . , 

data provided by the other party, which was encrypted with Accordingly, there is a need to a develop a system that 
their private key. Once the validation is complete, they have empowers the user with the tools to securely store and 
high assurance they are in communication with the indi- manage cryptographic keys and certificates along with criti- 
vidual named in the certificate. cal application data used with these assets to conduct 
To securely exchange messages they can use a combina- electronic transactions. Simply keeping private keys stored 
tion of both public and secret key cryptography. To send a in the user's computer may not adequately protect them 
secure message, the sender will generate a secret key and use from such malicious applications that attempt to locate and 
this to encrypt the message using a secret key algorithm. expose the user's private keys. Moreover, designing specific 
Encryption transforms the message from plaintext into some hardware/software solutions for every data exchange appH- 
meaningless ciphertext that is not understandable in its raw cation is not particularly useful or workable for a broad 
form and cannot be deciphered by an eavesdropper. The 20 public system with millions of users, 
secret key is then encrypted using the recipients public key j^^^u ^ desirable to develop a platform which sup- 
exchange key. Both the encrypted key and encrypted mes- ^ ^^^^^^^ appUcations that a user might 
sage are then sent to the recipient. Furthemiore, to ensure ^^jertake. For instance, it would be convenient and efficient 
that the message is not altered in any way, or is replaced, the ^ .a. 1 1 i_ j • j _x • 1 . • 

J 1 J- % 11 • • *i_ • tor the same plattorm to be used m conductmg electronic 
sender may also digitally sign the message using their 25 ^ 1 vwiiviuviin^ viv^n^iiiv 
private signing key. * & commerce over a network, or authenUcating a user for 
T T * * r *i. • J * J *i_ • * point-of-sale transactions, or managing a user's banking and 
Upon receipt or the signed encrypted message, the recipi- ^ \, ^ . • t t* . 
ent first decrypts the secret key using their private key "^^^^ ^^"^^ «^ electronic application Most 
exchange key. They can then decrypt the message using the ^^f^^ applications require access to the user s cerUficates 
secret key and the same secret key algorithm which trans- 3. ^nd keys. However, these different apphcations typicaUy 
forms the message from its ciphertext back to its plaintext. i°^olve interaction with different computers, such as the 
Only the recipient is presumed to have the abiUty to decipher ^^^'^ own computer, an employer's computer, a banking 
the message since only the recipient has possession of its electronic ticketmg machme, and so on. 
private exchange key. The recipient verifies the authenticity To support multiple applications, the platform must 
of the sender's digital signature using the originator's public 35 enable a user to transport certificates and keys from one 
signing key (which it received in the originator's certificate) application to another in a secure manner. This would pennit 
to assure itself that the contents are from the legitimate the user, for example, to gain access to his/her bank accounts 
sender and have not been subsequently altered. in a banking context, to exchange information with a col- 
Encryption, decryption, digital signing, and verification league electronically over a public network in a secure 
are therefore the principal cryptographic primitives that are 40 manner, and to digitally sign a purchase order in an elec- 
used in an electronic network setting to facilitate the tronic shopping context. It is inadequate to transport the 
security, privacy, authenticity, and integrity of information certificates and keys on a memory disk as theft of the disk 
being exchanged. would compromise the keys. Even encrypting the keys 
The secure information exchange is jeopardized, before loading them onto the memory disk would not prove 
however, if the private keys are discovered through theft or 45 ^^^P^^ ^^^^ '^^^^'^ eventually be decrypted at 
user mishandling. The private keys must be kept confidential some time in the future to perform a cryptographic function, 
to ensure security. However, in the computerized network always leaves a point where the pnvate keys are 
setting, there are potential hazards of using private keys in available m unencrypted format and thus, exposed to copy- 
the cryptographic functions within available personal com- or unauthorized use. 

puters or workstations. Since the functions are carried out 50 Accordingly, another design goal is to provide a multi- 
electronically, the user might assimie the cryptographic application platform which offers secure storage and trans- 
routines are operating as expected, yet not be aware of portation of private keys for use in different application 
ignorant or sophisticated electronic attacks. Careless appli- contexts, without jeopardizing or exposing the private keys, 
cations might use cryptographic exchange or signature keys Given these goals, there are countervailing concerns that any 
in ways that jeopardize the key's secrecy. Moreover, mali- 55 solution be cost effective, highly reUable, and difficult to 
cious applications might even deUberately compromise the compromise from a security standpoint, yet readily tailor- 
user's secrecy, or worse, perform unauthorized crypto- able to a user's needs and preferences, 
graphic operations. For instance, a malicious application rvTrrr-vT^^KT 
might attempt to decrypt the user's secret files and transmit SUMMARY OF THE INVENTION 
them to some adverse party. Another situation might involve 60 This invention provides a uniform platform for conduct- 
an application attempting to digitally sign notes or lOUs on ing electronic transactions in multiple different environ- 
behalf of the user without the user's knowledge or consent. ments. The platform is based upon use of a portable, 
A computer implemented cryptographic system must there- multi-purpose, integrated circuit (IC) card and compUmen- 
fore provide the needed security to prevent attack from tary computer software which enables user access and 
poorly devised or malicious applications. 55 management of resources maintained on the IC card. The 
Today, there are several electronic systems that provide software runs on a user's personal computer, empowering 
cryptographic services in the computer forum. These include the user to initialize the IC card, configure the card with the 
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resources that the user wants to maintain on the card, and to The card management services module implements the 

manage those resources. The software enables the user to administration functionality for the application for manag- 

generate private/pubhc key pairs and establish or change ing resources maintained on the IC card. When the appli- 

passcodes for access to the card resources. The IC card itself cation requests performance of an administrative task on the 
provides the electronic vehicle for securely transporting the 5 ic card, the card management services module communi- 

user's private keys and certificates without exposing them in ^ates with the IC card to perform the administrative task 

plaintext form. The IC card is designed with enough pro- requested by the application. For example, the card man- 

cessmg capabilities to perform rudimentary cryptographic agement services module might support administrative tasks 

functions so that the private keys may be employed for ^^^^ iiutialization of the IC card, generation of crypto- 

sigmng encryption, and decrypUon without ever being ^^.^ ^ ^^^^^ configuration, and management of 

exported from the card. f, j f um T- * L u . j 

^T, ,1 I- . . . . • the IC card storage capabilities to hold certincates, and 

More particularly, one aspect of this mvention pertains to assets 
a system having a multi-purpose IC card, a card reader 

which interfaces with the IC card to transfer information to Another aspect of this invention is a card manager user 

and from the IC card, and a computer coupled to the card interface (UI) which presents different graphical dialog 

reader to control the information transfer between the card screens to assist the user in managing her card resources, 

reader and the IC card. As an example implementation, the The card manager UI is very valuable from a usability 

system can be implemented as a home computer, equipped standpoint. It provides a consistent presentation and method 

with a card reader, and a generic smart card owned by the for managing the IC card resources which is independent of 

user. the applications being supported. The card manager UI 
The system further includes various applications which 20 allows the user to examine the resources of the card by using 

execute on the computer, or more specifically, which run on icon representations of the resources. The user can configure 

the computer's operating system. For example, the applica- his/her card to add or remove resources simply by manipu- 

tions might include a banking application, which is orga- lating the graphical icons. The card manager UI also enables 

nizes the user's finances in conjunction with a particular the user to initialize the IC card, and change passcodes for 
bank; or an electronic commerce application, which allows 25 accessing the IC card. 

the user to shop and purchase products over a public a.u »f.i. ' j 

, ^ ^ . f- *• u- u •* *u . Another aspect of this invention concerns the IC card 

network; or a travel application, which permits the user to n- ^ • . j • wt^\ j i_ j . 

make vacation reservations; or an entertainment application, integrated arcmt QC) card has a processor, a data 

which enables the user to purchase tickets for entertainment ^° the processor to receive and output 

events; or a gatekeeper application, which oversees access 30 ^ ^'r.l^?I^' ^"^^ a programmable data memory 

. .1. ^1 > IT r.u (example EEPROM or Flash memory). Such cards are 

onto the network of the user s employer. In any one of these v-^-^y'" ■ um^^,,,. v^uw. 

contexts, the application might require access to certain ^T^'^^ from multiple sources and m several form factors 

resources maintained on the IC card. Card-based software supports the fiinctionality reqmied, and 

™_ , i7 • 1 J 1 • . • • . ^ mterfaces, provided by the software runnmg on the PC. This 

The system further includes an application interface j r* -i c uf j * 

... 1 . t- 1- card software provides for programmable data memory 

which executes on the computer to implement each apph- 35 . . ... . , . 

, , . , . I.- L r -iv . . partitioned mto a pubhc storage and a pnvate storage, 

cation and to provide services which facilitate access to the >.r;j.i j- . -.r • 

*u J *u * * J L .u 1* Confidential mformation, such as pnvate keys, are mam- 
resources on the IC card that are requested by the apphca- . • j - • . . kt c j 1 

^ 1' • . _r • r Li • 1 : J tained in the private storage. Non-confidential user 

tion. The application mterf ace is preferably implemented as x_ .■,■, ,11. 

r e *• . J • 1 mformation, such as standard medical data, can be kept m 

a service layer for the operating system, and is securely li • . ^ • c j * 

. J -.1. : • . 1 .1. the public storage. The processor IS configured to access the 

mtegrated with the operatmg system via mutual authentica- 40 • . . r j . 1 

* J 1- / • . r ^ .1. pnvate storage of the data memory only after the processor 

tion procedures. The application interface supports three -^1 j i- j u a. 1 *u 

J. . , - . • I J /• vermes a passcode supphed by the user. Conversely, the 

distinct types of services. These mclude (1) configuration \ n j , .i_ ui- * j 

'"i- . . -.-I- J n processor is configured to access the pubuc storage and 

services which permit a user to imtiauze and configure the .... . . • i_ . • • • . j .• 

ir> J -.1. .1. * '1 J * » output Its contents without requinng receipt and verification 

IC card with those resources tailored to the user s - f, j ^ , ; j 

^ u- . t_i . .L of the user passcode. The partitioned storage and access 

preferences, (2) secunty services which enable access to the 45 , , ^ ^ *. r.. . i_- 1 
^ , V ' c. T. J J protocol promote secunty of the cryptographic keys, 

cryptographic functionality on the I C card, and (3) resource jr t=r r j 

management services which permit the user to manage the BRIEF DESCRIPTION OF THE DRAWINGS 

storage provided by the IC card. 

In one implementation, the application interface com- The same numbers are used throughout the drawings to 

prises a cryptographic services module and a card manage- 50 reference Uke elements and features. 

ment services module. The cryptographic services module FIG. 1 is a diagrammatic illustration of a system having 

implements cryptographic functionaUty for the application. a network-attached computer with integrated circuit (IC) 

The cryptographic services module uses cryptographic card and reader. 

resources maintained on the IC card and supplements this pjQ 2 is a block diagram of a software/hardware archi- 
with software services. When the application requests a 55 lecture for the FIG 1 system 

cryptographic function, the CH'Ptographic services module 3 ^ ^j^^^ ^ 

communicates with the IC card to have the IC card support ^ 

the cryptographic function. The IC card lends support with- ^ ^ diagrammatic Ulustration of a graphical dialog 

out exposing the cryptographic resources maintained screen generated according to a card manager user interface 
thereon. As an example, if the application requests a digital 60 executing on the computer. 

signamre on a message, the application calls the crypto- FIG. 5 is a diagrammatic illustration of another graphical 

graphic services module to hash the message to produce a dialog screen generated according to the card manager user 

digest and passes the message digest to the IC card. The IC interface executing on the computer, 

card then digitally signs the digest using the user's private FIG. 6 shows a diagrammatic illustration of a card-based 
signing key and returns the signed digest to the application 65 system which permits secure transportation of cryptographic 

interface without exposing the signing key. The IC card can keys, certificates, and digital assets from an application at 

also assist in encryption, decryption, and authentication. one cite to another application at another cite. 
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FIGS. 7-12 present a flow diagram of a method for might, however, be implemeated in other forms with differ- 

conducting an electronic purchase transaction using the IC ent appearances. For example, the computer 12 might be 

card-based system. implemented as a PC-based point-of-sale machine or kiosk 

that is employed by merchants, or an automatic teller 

DETAILED DESCRIPTION OF THE 5 machine (ATM) used by banks, or a computerized vending 

PREFERRED EMBODIMENT machine, or an electronic ticket apparatus, or a set-top box. 

. . J. There are many different forms that the computer 12 might 

The followmg discussion assumes that the reader is assume, with each possible computer implementation being 

familiar with cryptography. For a basic introduction of capable of exchanging data with the IC card, 

cryptography, the reader is directed to a text written by Depending upon the computer configuration and its oper- 

Bruce Schneier and entitled "Applied Cryptography: ating environment, one or more software applications 

Protocols, Algorithms, and Source Code in C," published by execute on the computer. A user's home or work computer 

John Wiley & Sons with copyright 1994, which is hereby typically executes many different applications. Conversely, 

incorporated by reference. a computer implemented as a kiosk, ATM, or vending 

FIG. 1 shows a computer system 10 having a computer 12 machine might only execute one specific application. The 

and a multipurpose integrated circuit (\C) card 14. The applications typically run on an operating system that is 

computer 12 includes a central processing unit (CPU) 16, a executing on the computer 12, The operating system is 

monitor or display 18, and a keyboard 20 (or other input preferably a disk-based graphical operating system, such as 

device). The computer 12 is connected to a network 22 via Windows® 95, Windows® NT, or other Windows®- 

a cable or wireless connection represented by line 24. The compatible systems, although^her operatmg systems can 

network 22 can be a data communications network including '° employed, such as MS-DOS® or a customized operating 

a wire-based network, such as an enterprise network (e.g., a ^^^^"^ ^P^^^^^ ^^^^f for a particular environment, 

local area network for a business) or a public network (e.g., ?°m''i2"'^T ""''"^ ''''''T T'"''"" 'T^^ 

the Internet), and a wireless network (e.g.,sateUite network). ''}^^' V fPP^^.^^' "° apphcation 

™ ^ ,-,-» 11- executmg on the computer 12. Among these resources are 

The neuvork 22 can also be miplememed as a telephone t f h capabiliUes. The IC card stores pubHc and 

network, or an mteracUve television network, or any other ^vate key pairs and can hold related data such as pubUc key 

form for hnking the computer 12 to an external source of certificates. The IC card also performs rudimentary crypto- 

information. graphic functions, including encryption, decryption, signing. 

The IC card 14 is a portable card-like device with pro- authentication. The IC card may also contain resources in 

cessing capabilities, allowing it to be used for many different 3Q the form of electronic assets, which represent value. For 

purposes. In the illustrated implementations, IC card 14 is a instance, the IC card might store assets in the form of 

smart card. A "smart card" is the approximate size of a electronic entertainment tickets, travel reservations, service 

standard credit card and has a built-in microcontroller contracts, medical prescriptions, government entitlement 

(MCU) 28 which enables the card to modify, or even create, provisions, electronic cash, public transportation tokens, and 

data in response to external stimuli. The microcontroller 28 35 so on. With such diverse resources, the IC card 14 is capable 

is a single wafer integrated circuit (IC) which is mounted on of supporting multiple applications in different environ- 

an otherwise plastic card. A smart card is physically con- ments. 

structed in accordance with the international standard ISO- Before this invention, the IC cards have generally sup- 

7816 which governs size and bendable limits of the plastic ported only a very Umited set of applications, most com- 

card, as well as size and location of the silicon integrated monly a single application, which were pre-programmed at 

circuit. An example smart card implementation is described time of manufacture. It has been tacitly assumed that the end 

in more detail below with reference to FIG. 3. In other user lacks the facilities to configure and manage the IC card, 

implementations, the IC card might be in the form factor of As a result, the user has needed multiple cards to support 

a PCMCIA card (i.e., PC card) or a floppy diskette, with one various applications. For instance, a user might have an 

or more processing chips configured thereon. Accordingly, 45 access card that he uses to enter his work place, a bank card 

as used in this disclosure, the term "IC card" means a that he uses to access his bank account, a token card that 

portable, low energy, electronic device with processing allows him to ride public transportation, and so on. An 

capabilities and memory. Such devices typically lack their aspect of this invention, however, is to provide both a 

own user interface (i.e., a keypad or display), but can be multi-purpose IC card 14 which can be employed in many 

constructed with some user interface capabilities. jq different environments as well as the tools which will allow 

A card reader 26 is coupled to the computer 12. The card the user to manage that card and its supported applications 

reader 26 interfaces with the IC card 14 (electrooicaUy, over time. The net result will be that the end user can do 

magnetically, RF, or otherwise) to transfer information to more while carrying fewer cards. 

and from the IC card. In this implementation, the IC card 14 The multi-purpose IC card 14 provides a safe means for 

is physically inserted into a slot in the card reader 26 (as 55 transporting the resources stored thereon. The I C card 14 can 

represented by the direction arrow). Interface pads on the be physically ported with the user fi-om place to place. The 

card's MCU 28 make electrical contact with leads in the card die design and fabrication processes used to manufacture the 

reader, forming an electronic interface between the IC card microcontroller IC yield a highly tamper-resistant card that 
14 and the computer 12. Following a transaction, the IC cardl is very difficult to reverse engineer and extract information, 

is removed from the card reader 26 and transported with the Uq Thus, even if the card were lost or stolen, it is very difBcult 

user. In other implementations, the card reader 26 might be I to obtain confidential information in the short time frame 
implemented to communicate with the IC card 28 in a] before the card is reported as lost and marked inactive. The 
wireless or remote fashion without the physical coupling^ IC card thus offers a secure storage and transportation 

The computer 12 controls the information transfer mechanism for the cryptographic resources, and namely, the 

between the card reader 26 and the IC card 14. The iUus- 65 private keys. 

trated system represents a typical desktop computer that a The computer system 10 includes a software apphcation 

user might use at home or work. The computer system interface which executes on the computer 12 to prevent 
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possible covert attacks from malicious software applications cryptographic resources maintained on the IC card 14. When 

which attempt to gain unauthorized access to resources on the application 34 requests a cryptographic function, the 

the IC card. The application interface implements the appli- cryptographic services module 40 communicates with the IC 

cation and provides services which facilitate access to the card 14 and works cooperatively with the IC card 14 to 

resources on the IC card 14, without allowing the application 5 perform the cryptographic function without exposing the 

itself to directly access the card-based resources. The appli- cryptographic resources maintained on the IC card 14. As an 

cation interface is implemented as a service layer for the example, the cryptographic services module 40 supports the 

operating system and is securely integrated with the oper- following requests from the apphcation: generating one or 

ating system through mutual authentication. During more cryptographic keys on the IC card, retrieving the 

initiahzation, the application interface and the operating public component of a public/private cryptographic key pair 

system exchange certificates containing identifications (i.e., from the IC card, adding a certificate (or other data resource) 

serial numbers or the like) which are signed by a trusted to the IC card, retrieving a certificate from the IC card, 

certifying authority (e.g., the manufacturer). The operating deleting a certificate from the IC card, generating a message 

system and apphcation interface then authenticate each other digest based on an application suppUed message, signing a 

using the certificates. One technique for authenticating the message digest, encrypting data supplied by the apphcation, 

various components in a computer system is described in a decrypting data supplied by the application, verifying a 

co-pending U.S. patent application Ser. No. 08/531,567, signature supplied by the application, encrypting an encryp- 

now U.S. Pat No. 5,221,781 filed Sep. 13, 1995, entitled tion symmetric key for key exchange, decrypting a sym- 

"Authentication System and Method for Smart Card Trans- metric key supplied by the application. An example set of 

actions." This application is hereby incorporated by refer- API calls is described below. 

ence. 20 In the illustrated implementation, the cryptographic ser- 

The apphcation interface is preferably an apphcation vices module 40 comprises a cryptographic apphcation 

program interface with a set of functional APIs that can be program interface (CAPI) 42 which provides functionahty to 

called by the apphcation to support a particular fiiinction- the executing apphcation 34 and one or more cryptographic 

ality requested by the application. An example set of APIs service providers (CSPs) 44 which implement the crypto- 

are described below in more detail. 25 graphic functionality presented by CAPI 42 to the apphca- 

FIG. 2 shows an architecture of the computer system 10. tion 34. The CAPI layer 42 is thin. Its principal task is to 

It generally consists of three software layers and two hard- select an appropriate CSP and verify its authenticity. When 

ware layers. At the lowest hardware layer, there is an the application 34 needs a sequence of cryptographic func- 

electrical interface (direct or remote) between the IC card 14 tions to be performed (e.g., encryption, decryption, signing), 

and the card reader 26. An I/O controller 30 is pK)vided at 3Q the apphcation invokes the CAPI 42 to acquire a context 

a hardware interface layer to control the data transfer to and associated with the appropriate CSP. The CAPI 42 then 

from the card reader. The I/O controller 30 is typically loads the CSP and verifies its authenticity. Each CSP is 

implemented as a control board resident in the computer digitally signed by a certifying authority using that authori- 

CPU and connected to the CPU bussing structure. A soft- ty's private signing key. A corresponding public signing key 

ware driver 32 defined by the operating system controls 35 of the certifying authority is embedded in the CAPI 42 so 

operations of the card reader 26 through the I/O controller that the CAPI 42 can verify the authenticity of the CSP 44 

30. by validating the digital signature of the certifying authority. 

The multiple apptications, referenced generally as number This verification prevents introduction of a foreign or impos- 

34, run on the operating system at a high level, apphcation tor CSP. 

layer. The API layer, referenced generally as number 36, 40 The CAPI 42 also provides an insulating layer between 

resides between the application layer and the driver layer. the application and the CSP so that the application never has 

The application interface 36 is a service layer which sup- direct access to the CSP, but can only call to the CSP through 

ports three distinct types of services: (1) configuration the CAPI. The CAPI 42 is preferably implemented in 

services which permit a user to reconfigure the IC card with software, which is stored in memory of the computer 12 and 

those resources tailored to the user's preferences; (2) secu- 45 executed on the CPU 16, 

rity services which enable access to the cryptographic func- The CSPs implement the cryptographic functionahty 

tionahty on the IC card; and (3) resource management requested by the application. In general, the CSPs perform 

services which permit the user to manage the resources encryption/decryption services, authentication, key 

provided by the IC card. exchange tasks, hashing routines, and digital signing. A 

The API 36 includes a card management services module 50 different CSP can be configured to perform each of these 

38 and a cryptographic services module 40. The card man- functions, although a single CSP can be implemented to 

agement services module 38 implements administration perform them all. Each CSP, or a dedicated CSP, can be 

functionality for the applications 34 for managing resources configured to communicate with the IC card 14. The CSPs 

maintained on the IC card 14. When the apphcation requests 44 are independent from, but dynamically accessible by, the 

that an administrative task be performed on the IC card 14, 55 CAPI 42 using conventional loading techniques, 

the card management services module 38 communicates The CSP is preferably implemented in software as 

with the IC card to perform the administrative task. As an dynamic linked hbraries (DLLs). This implementation is 

example, the administrative tasks include initiahzation of advantageous because it can be easily invoked by the CAPI 

the IC card, cryptographic key generation, passcode or by the apphcation through the CAPI. Furthermore, the 

configuration, management of cryptographic keys on the IC 60 cryptographic functions can be changed or updated simply 

card, management of certificates on the IC card, and man- by replacing one or more DLLs. With the CAPI layer in 

agement of assets on the IC card. The interface presented to between, the CSP DLLs can be replaced without affecting 

the user by the card management services module is con- how the application interacts with them. Additionally, by 

sistent and application independent for usability. An packaging the cryptographic services in DLLs, it will be 

example set of API calls is described below in more detail. 65 possible to change the strengths of the services as regulatory 

The cryptographic services module 40 implements cryp- considerations change without impacting the higher level 

tographic functionality for the application 34 while using apphcation. 
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A more detailed explanation of a cryptographic system noo-confidential user information 74, such as medical data 

which employs the CAPI and CSP architecture is found in or driver's license information. This information is distrib- 

a co-pending U.S. patent application Ser. No. 08/496,801, uted freely by the IC card 14, without any special security 

now U.S. Pat. No. 5,689,565 filed Jun. 29, 1995, entitled protocol or the need for the user to enter a personal passcode. 

"Cryptography System and Method for Providing Crypto- 5 jhe private storage 72 maintains information of which the 

graphic Services for a Computer Application." This apph- ^^^^ wishes to control distribution. The processor 50 only 

cation was filed under the names of Terrence R. Spies, retrieves information from the private storage 72 upon 

Jeffrey F Spelman, and Daniel R. Simon and is assigned to authorization by the user as indicated when the user enters 

En^b refeE'°°* W^cation is mcorporated ^ ^^^^^^ passcode. This passcode is entered into the 

^ ,^ . ■ , , , . , 10 computer, passed through the card reader to the card I/O 

The IC card 14 stores and manages the cryptographic keys , j ^„ .u^ en tu^ en 

- . J J J. ^_ >.c^n /a ' port, and on to tiie processor 5U, Ine processor 5U compares 

and associated data resources used by the CSP 44 m per- fi. * j j * j 4^ * j ■ T:nmr\i^jt 

c . . L- XL the entered passcode to a passcode 76 stored in EEPROM 

formmg the cryptographic function. The IC card 14 can also _^ , ^ , . . * j • * 

& /ror u-iL *- ■ ^ c 56, and permits access to contents stored on the pnvate 

perform rudunentary cryptographic functions m support of ' r . . j j . j j . l 

the CSP 44 ^ & r rr storage 72 if the two entered and stored passcodes match. 

An advantage of the FIG. 2 architecmre is that the API 36 ''r^^ Pnvate storage 72 of EEPROM 56 stores two asym- 

H TP nard 14 nfF^^r . uniform nlatfnrm whi^^h simnnrt.^ / "metric pairs of public and private cryptography keys 

68 — the signing pair and the exchange pair One or more 



and IC card 14 offer a uniform platform which supports 
many different applications. Independent vendors can 
develop different applications which employ the services 
provided by the API 36, without needing to write hardware 
specific code for accessing the IC card. Additionally, the 
layered architecture and inherent tamper-resistance of the IC 
card promotes security of the private keys. 



certificates 78 are also stored in the private storage 78. These 
certificates might contain a card ID, or user ID, public keys, 
and a signature of a certifying authority. One certificate 
might be used in a number of different applications, or 
alternatively, for only a specific corresponding apphcation. 



no. 3 shows the IC card 14 implemented as a smart card, "^^^ designed to avoid exposing the private 

and particularly, shows the microcontroller 28 of the IC card ,5 ^^^ys. The encryption keys are never directly accessible and 

14. The MCU 28 has a CPU or processor 50, a volatile asymmetric pnvate sigmng and exchange keys are not 

rewritable RAM (Random Access Memory) 52, a ROM permitted to leave the IC card under any circumstances. In 

(Read Only Memory) 54, and an persistent reader/write this manner, the IC card prevents a foreign application from 

memory such as EEPROM (Electrically Erasable Program- ever inadvertently or intentionally mishandling the keys in a 

mable ROM) 56. A multi-bit bus 58 connects the compo- 33 t^^* ^^^^^ ^^^^e them to be intercepted and compro- 

nents. Interface contacts or ports 60 are shown as an naised. 

example coupling for an electronic interface. These include When an application 34 requests cryptographic functions, 

clock, reset, power, data I/O, and ground. Data is transfer is the IC card 14 works in cooperation with the CSP 44 to 

controlled by CPU 50 through serial I/O port 60 and provide cryptographic functionality. The CSP performs most 

conductor 62. 35 the of encryption and decryption processes which require 

This invention includes implementation of system greater computational resources. With present technology, 
software, held in mask ROM, for IC cards such as those IC cards in general cannot adequately perform full 
described above. This system software is designed to be encryption/decryption of large size documents/messages 
tightly coupled with the cryptographic services and card due to 1/0 and processing limitations of the small micro- 
administrative modules previously described to create a 40 controller. However, the IC card can provide signatures and 
complete multi -application system. The IC card is config- verification functions, and is capable of encrypting or 
ured with various cryptographic functionality to support the decrypting small messages. As technology continues to 
cryptographic services module 40 in the API 36. In the evolve, it is expected that IC cards will have powerfuU and 
illustrated embodiment, the IC card 14 is configured with fast processors that can satisfactorily encrypt messages of 
cryptography acceleration circuitry 64, shown integrated 45 any size and sign them within the context of the desired 
with the CPU 50, which sU-eamlines cryptography compu- environment without noticeable or irritating delay, 
tations to improve speed. The cryptography accelerator 64 With continuing reference to FIG. 3, electronic assets 80 
can alternatively be implemented independently of the CPU. are also stored in the private segment of the EEPROM 56. 
The ROM 54 stores a cryptographic program 66 which These electronic assets represent value, and might include 
executes on the CPU 50 in conjunction with the cryptogra- 50 tickets, tokens, e-cash, service contracts, medical 
phy accelerator 64 to perform certain cryptographic prescriptions, reservations, government entitlements, or a 
functions, including encryption, decryption, signing, and pointer to a source of value. Non-cryptographic programs 82 
verification. that the user might wish to load onto the IC card are kept in 

The cryptographic program 66 can be implemented as one the EEPROM 56. These programs can be complimentary 

or more cryptographic service providers (CSPs) to perform 55 routines that assist the appfications running on the computer 

these cryptographic functions. As an example, the crypto- to organize or manipulate data and assets on the card, 

graphic program 66 can encrypt and decrypt short messages Unlike prior art IC cards and readers which are factory 

using asymmetric key cryptography, such as RSA, and configured and offer limited, if any, customization by the 

symmetric key cryptography, such as DBS (Data Encryption user, the computer system 10 permits the user to extensively 

Standard). The cryptographic program 66 might also be eo configure the IC card 14 according to his/her preferences 

capable of generating and destroying cryptographic keys, after the card has been issued. As shown in FIG. 2, the 

such as symmetric keys used in the bulk encryption/ computer system 10 has a card manager user interface (UI) 
decryption of a message. The symmetric keys are typically? 84 executing on the computer CPU at the apphcation layer, 
/'sessional," meaning they are generated for each transaction/ The card manager UI 84 presents a uniform set of graphical 

and then subsequently destroyed. ^ 55 dialog screens which enable the user to conveniently and 

The EEPROM 56 is partitioned into a public storage 70 easily manage the card resources (including cryptographic 

and a private storage 72. The public storage 70 contains resources, assets, etc.) from the computer. 
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FIGS. 4 and 5 show an example of a card manager prior art systems, which were proprietary and closed to user 
graphical pop-up box 90 having different graphical dialog configuration, the computer system 10 promotes user con- 
screens that are generated by the card manager UI and trolled management of the card through the API 36 and card 
displayed to the user. FIG. 4 shows an example passcode manager UI 84. 

dialog scr^n 92 which allows the user to change his/her 5 ^ ^^^^'^ ^ ^ illustration of how the IC card 

passcode. To reach this screen, the user inserts the I C card ^ ^^^^^^^ applications, whUe securely 

into the card reader and enters the appropnate passcode to . • j t ^i.* / 

verify the user to the IC card. Thereafter, the user selects the , the resources on the card. In this example 

card manager dialog box 90 and pulls up the passcode screen illf t^^tion, IC card 14 is configured with the user s medical 

92 to change the passcode. The user enters the old passcode, information, financial data, work access account, tokens for 

then the new one, and confirms the change. A card icon 94 beverage and snack vendmg machmes, and various onHne 

along the bottom enables the user to select the appropriate IC service accounts including an electronic shopping account, 

card, in the event the user has more than one IC card that The user first inserts the IC card 14 into his/her home 

requires management. computer 120 for initialization and configuration using the 

When the user changes the passcode, the new passcode is card manager UI. Using the card manager UI, the user sets 
passed to the card management services module 38 of API '^^ the IC card to an initial state in which the memory is cleared. 

36. This services module accesses the card and overwrites The user then establishes one or more passcodes, which are 

the old passcode stored in the EEPROM 56 of the IC card stored on the IC card. Next, the user configures the IC card 

with the new passcode. with certain resources to tailor the card to his/her prefer- 

FIG. 5 shows an example resource management graphical ences. 
screen 96 which is also part of the card manager pop-up box As part of the configuration, the cryptographic services 
90. The resource screen 96 provides a convenient interface module 40 of API 36 instructs the IC card processor 50 to 
that allows the user to manage the resources maintained on generate a unique signing pair of public/private keys and a 
the card. The resource screen 96 presents a list 98 of unique exchange pair of public/private keys. The user con- 
resources that are presently stored on the user's IC card and nects to a certifying authority via a public network 122 (e.g., 
a resource list 100 of available resources that can be added the Internet) and sends identification information along with 
to the card. The icons represent various resources, such as the public keys to the certifying authority. The certifying 
parental control features 102, financial account access 104, authority returns a certificate containing the identification 
entertainment -related assets 106, medical information 108, information and public keys, and a signatiu-e of the certify- 
travel reservations 110, and telephone assets 112. ing authority. The certificate is stored on the IC card 14. 

The user manipulates the icons to add assets to, or remove Now suppose the user transports the IC card 14 to work, 

assets from, the IC card. This can be done using a conven- The user inserts the IC card 14 into his/her workstation 

tional drag-and-drop protocol where the user clicks on the computer 124 which is attached to the company network 126 

desired icon using a mouse or other pointing device, and (e.g., Ethernet LAN). The user enters the passcode to 
drags the icon to the appropriate location. For instance, the 35 activate the IC card. The security application running on the 

user can drag the travel icon 110 from the resource list 100 workstation computer (or elsewhere on the network) then 

to the card list 98 to add this resource to the card. In the communicates with the IC card to verify the IC card (and 

illustrated example, a travel-relate asset (i.e., ticket hence the user) for access to the services on the network. The 

reservations) has been added to the user's card. The IC card IC card might also wish to verify the authenticity of the 

is thus equipped with travel accommodations and the user security application. This can be done by exchanging 

can port the IC card to the airport to download this travel authentication information between the security apphcation 

asset when checking in for the flight. Other task-oriented and the IC card. 



input protocols, in addition to the drag-and-drop protocol, 
can be used to manage the resources on the IC card. 

When the user manipulates the resources on the IC card, 45 
the card management services module 38 perfonns the actual 
card maintenance. For instance, to add a ticket-related asset, 
the card management services module 38 downloads the 
new "ticket" (i.e., application defined electronic representa- 
tion of the ticket) to the IC card which is stored in the 50 
EEPROM. As another example, to add new cryptographic 
resources, the card management service module 38 might 
reconfigure the processing capabilities of the IC card by 
updating or changing a stored programs kept in memory the 
IC card read/write memory. 55 

The passcode screen 92 (FIG. 4) and the resource man 



^ After work, the user ports the IC card 14 to a banking 
ATM 128 to withdraw cash. The ATM is an online computer 
attached to a proprietary bank network 130. The user inserts 
the IC card 14 into a card reader and enters his/her passcode 
(which coxild be different than the passcode used for work or 
home) to authenticate the user to the IC card. Next, the IC 
card and banking application running on the ATM exchange 
authentication information. The banking application then 
conducts a financial transaction through the API to the IC 
card. In the cash withdrawal operation, the IC card signs a 
request for cash using a private signing key on the IC card. 
The request is transferred to the ATM banking application 
through the API without exposing the signing key. The ATM 
then transfers electronic cash to the IC card 14 and debits the 



agement screen 96 (FIG. 5) are shown for example purposes. \user's account. The electronic cash is stored in the private 

There can be many other types of screens. For example, a storage of the programmable memory of the IC card 14. 

certificate screen 114 permits the user to manage various The user is free to spend the electronic cash on various 

certificates which have been issued for the public keys eo goods and services, such as tokens for public transportation, 

stored on the IC card and associated with various applica- food at a grocery store, and so on. As a further example, 

tions such as authentication, electronic payment, electronic suppose the user decides to purchase a beverage firom a 

travel, etc. An initiahzation screen 116 enables the user to vending machine 132. The user transports the same IC card 

initiahze the IC card to an initial state. After initialization, 14 to the vending machine 132 and inserts it into a com- 

the user can configure the IC card to his/her preferences. 65 patible card reader. The vending machine is an example of 

With the use of the card manager UI, the multi-purpose IC an offline computer, one that is not attached to a back end 

card can be configured and managed by the user. Unlike network. When the user selects the beverage, a vending 
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machine application running on the vending machine 
requests through the API that the monetary equivalent of the 
cost of a beverage be withdrawn from the IC card 14. To 
access the private storage, the user might be requested to 
enter a passcode which is verified to the IC card. On the 
other hand, for such low cost items, there may be no need to 
verify the user via the passcode, or any other security 
protocol. The IC card 14 exports assets sufficient to pay for 
the beverage to the vending machine application, which then 
releases the beverage. 

Now suppose on the way home, the user is injured and 
requires evaluation at a hospital 134. The IC card 14 can be 
accessed at the hospital to download the user's medical 
information from the public storage of the IC card's 



10 



compares the passcode with one stored in memory for 
purposes of verification (step 152 in FIG. 7). If the entered 
and stored passcodes match, the user is presumed authentic 
and the IC card is prepared for interaction with a selected 
application. 
Certificate Exchange 

Suppose the user wishes to purchase a product from a 
merchant over a public data network, such as the Internet. 
The user begins a commerce application 34 on his/her 
computer which enables the user to browse and purchase 
goods from the merchant (step 154). For this example, 
assume that the IC card 14 and the commerce application 34 
have already mutually authenticated each other through the 
exchange of certificates. 



EEPROM. This can be done without requiring the user's When the user is ready to place an order, the user and 
passcode in the event the user is i unable to function due to \ merchant computers will first exchange certificates. These 

are validated and the public keys contained therein are used 



10 
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30 



35 



the injury. 

After being released from the hospital, the user returns 
home. On doctor's orders, the user needs to purchase 
medical supplies to assist in the recovery. The user decides 
to buy the medical supplies from a merchant over the public 
network. The user inserts the IC card 14 into the home 
computer 120 and gains-access to the public network 122. 
The user finds a medical supplies merchant and initiates an 
order using a shopping application executing on the user's 
home computer, or remotely from the merchant over the 
network. Authentication information is exchanged between 
the IC card and shopping application for mutual verification. 
The user then places an order, which is encrypted and 
signed, and sends the order over the network to the mer- 
chant. The encryption and signing functions are performed 
cooperatively between the IC card 14 and the API executing 
on the user's home computer, while using the signing and 
exchange keys kept on the IC card. The private keys are 
never exposed to the merchant application. The merchant 
decrypts the order and verifies the user's signature. If valid, 
the merchant ships the medical supplies and bills the user. 

The FIG. 6 example demonstrates that the same IC card 
can be used in many different environments. Furthermore, 
the card can be easily configured to add additional capabili- 
ties as they come along. The IC card is a secure means for 
transporting the user's certificates, private/public key pairs, 
assets, and other information. Due to the sophisticated die 
processing techniques, the microcontroller die on the IC 
card is very difficult to reverse engineer, making it a very 
secure vehicle. The private keys are well protected. 
Moreover, the private keys never leave the IC card; rather, 
the complimentary API running on the computer facihtates 
data communication with the IC card to perform the cryp- 
tographic fuinctions without ever exposing the private keys 
to the API or application. 

To further demonstrate how the IC card and computer- 
based API work together to protect the user's keys, the 
following discussion provides a detailed example of an 
electronic purchase transaction between a user or purchaser 
and a merchant. This example is described in reference to 
FIGS. 1-3 and to the flow diagram of FIGS. 7-12, where 
FIGS. 7-10 represent steps taken at the user's premises and 
FIGS. 11-12 represent steps taken at the merchant's pre- 
mises. 

To begin the process, with reference to the flow diagram 
of FIGS. 7-10, the user inserts the IC card 14 into card 
reader 26 of computer 12. This computer might be, for ^ 
example, the user's home computer or a set-top box. The 65 
user enters a personal passcode which is passed to the IC 
card 14 for authentication (step 150 in FIG. 7). The IC card 



to enable a public key authentication protocol and to 
securely exchange symmetric key information if required to 
establish a secure communication channel. ' 

The API card management services module 38 executing 
on the user's home Computer instructs the IC c^d processor 
^ 50 to retrieve the particular certi^cate for this commerce 
apphcation (may Be in the IC card EEPROM 54, a hard disk, 
etc.- (as there can be more than one certificate), and exports 
the certificate to the application 34 (step 156). The user's- 
computer and the merchant's computing unit then exchange 
the certificates over the public network (step 158). 

Upon receipt of the merchant's certificate, the commerce 
apphcation submits the merchant's certificate through the 
card management and cryptography API 36 to the IC card 14 
(step 160). The card processor 50 examines the signattire on 
the certificate to verify that it belongs to the certifying 
authority in this context (step 162). If the certificate is valid, 
the merchant identifying information can be checked and the 
pubhc keys used to authenticate the merchant using a 
challengeresponse protocol. 
Encryption and Signing 

The commerce application generates an order, which is 
approved by the user (step 164 in FIG. 8), The order is 
encrypted so that it may be securely transmitted over the 
open and insecure public network. To perform the 
encryption, the commerce apphcation 34 supplies a plaintext 
order to the CAPI 42 to be encrypted and signed (step 166). 
The CAPI 42 selects the one or more CSPs 44 to perform the 
encryption and signing (step 168 in FIG. 8). This entails 
loading the appropriate DLL, and performing a series of 
calls, such as calls to begin and end the encryption and to 
digitally sign the result. For purposes of continuing 
discussion, the operation will be described as if the CSP 44 
is capable of performing all of the requested cryptography 
functions. 

Communication is established between the CAPI 42 and 
CSP 44 (step 170 in ¥IG. 8). The CAPI 42 verifies the 
authenticity of the CSP 44 by vaUdating the binding authori- 
ty's digital signature attached to the CSP 44 using the 
binding authority's public signature key embedded in the 
CAPI 42 (step 172). 

Once the CSP is authenticated, the CAPI 42 passes the 
plaintext order to the CSP 44 for encryption (step 174 in 
FIG. 8). The CSP 44 uses a hash function to translate the 
plaintext order into a cryptographic digest or hash (step 176 
in FIG. 9). A hash function is a mathematical function that 
converts an input data stream into a fixed-size, often smaller, 
output data stream that is representative of the input data 
stream. The CSP passes the digest to the IC card (step 178). 
The card processor 50 digitally signs the cryptographic 
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digest (hash) by encrypting the digest using the user's 
private signing key of the asymmetric key pair (step 180 in 
FIG. 9), as foUows: 

^Kjig».priM^r (Order Ha8h)-Signature 

The signing operation employs an asymmetric key algo- 
rithm which involves two separate keys, one key to encrypt 
the hash (i.e., sign) and one key to decrypt the hash (i.e., 
unsign). The keys are based upon a mathematical relation- 
ship in which one key cannot be calculated (at least in any 
reasonable amount of time) from the other key. The private 
signing key is kept by the user on the IC card, while the 
public signing key is distributed in the certificate to the 
merchant. An example asymmetric cipher is the well-known 
RSA cryptographic algorithm named for the creators Rivest, 
Shamir, and Adleman. 

The digital signature (i.e., signed hash) is returned to the 
CSP 44 (step 182) and attached to the order. The CSP 44 
generates a symmetric bulk data encryption key and 
encrypts the order and digital signature using the new 
symmetric encryption key (step 184 in FIG. 9). In a sym- 
metric cipher, the encryption key can be calculated from the 
decryption key, and vice versa. In many cases, the encryp- 
tion key and the decryption key are the same. The symmetric 
key must be known to both the sender and receiver, but 
otherwise kept secret. Once the symmetric key is divulged, 
any party can encrypt or decrypt messages. Example sym- 
metric ciphers are a DES (Data Encryption Standard) 
encryption algorithm or an RC4 algorithm. The encryption 
of the order and signature is represented as follows: 



^Ksym (order+signature)-order.enc 

It is noted that the IC card 14 might perform the key 
generation function of generating the symmetric session key 
and exporting them to the CSP 44. Additionally, when 
processing capabilities of the IC card improve, the IC card 
itself might perform the bulk data encryption. After the order 
is encrypted, the CSP 44 encrypts the symmetric encryption 
key using the key exchange public key of the merchant that 
was originally received in the merchant's certificate (step 
186), as follows: 

The asymmetric public/private exchange keys ensure that 
only the holder of the private key can decrypt a message that 
is encrypted with the corresponding public key. 

The CSP 44 returns the signed and encrypted order to the 
CAPI 42, which passes it onto the application 34 (step 188 
in FIG. 10). The symmetric key is exported from the CSP in 
encrypted format, not in plaintext format. Furthermore, the 
asymmetric private signing and exchange keys remain per- 
manently protected on the IC card and are not exposed to 
either the CSP or application. The order is then transmitted 
from the user's computer over the network to the merchant's 
computer (step 190). 
Decryption and Authentication 

With reference to FIGS. 11-12, the commerce application 
running at the merchant's computer receives the signed 
encrypted order and passes the package to its own API 
cryptography services module 40 (step 192 in FIG. 11). The 
encrypted order is supplied to the CAPI 42 for purposes of 
being decrypted and verified. The CAPI 42 selects the 
appropriate CSP or CSPs 44 to perform the decryption and 
verification (step 194). ITie appropriate CSP DLL is loaded 
and the application performs a series of calls to the DLL 



through the CAPI. Communication is established between 
the CAPI 42 and selected CSP 44 (step 196), and the CAPI 
42 verifies the authenticity of the CSP 44 (step 198). Once 
the CSP is authenticated, the CAPI 42 passes the encrypted 
order to the CSP 44 for decryption (step 200). The CSP 44 
decrypts the symmetric encryption key using the merchant's 
private key exchange key maintained on the merchant's IC 
card, or elsewhere (step 202 in FIG. 11), as follows: 
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The recovered symmetric key is used to decrypt the order 
and user's digital signature to provide the plaintext order and 
the signed cryptographic digest (hash) (step 204 in FIG. 11), 
as follows: 

^Kgym (order.enc)=order+signature 

At this point, the CSP passes the cryptographic digest 
(hash) to the merchant's IC card (step 206 in FIG. 12). The 
merchant's IC card verifies the signature by decrypting the 
hash using the user's public signing key which was received 
in the user's certificate (step 208). If the decryption yields a 
result that compares bit-for-bit with an independently, 
locally computed hash of the entire message (computed by 
the CSP and passed into the IC card), the merchant is assured 
that the packet came from the user and was not subsequently 
altered. This decryption and verification of the hash can 
alternatively be performed by the CSP if the merchant does 
not employ IC cards. If valid, the plaintext order is returned 
from the CSP 44 to the CAPI 42 and then to the commerce 
application 34 (step 210). After the process is completed, the 
CSP destroys the symmetric encryption key that was 
employed for that session. 

In compliance with the statute, the invention has been 
described in language more or less specific as to structure 
and method features. It is to be understood, however, that the 
invention is not limited to the specific features described, 
since the means herein disclosed comprise exemplary forms 
of putting the invention into effect. The invention is, 
therefore, claimed in any of its forms or modifications within 
the proper scope of the appended claims appropriately 
interpreted in accordance with the doctrine of equivalents 
and other applicable judicial doctrines. 

We claim: 

1. A system for supporting at least one computer- 
implemented application to access and manage a multi- 
purpose integrated circuit (IC) card, the system comprising: 

a multi-purpose integrated circuit (IC) card having a 
plurahty of resources for different uses; 

a card reader which interfaces with the IC card to transfer 
information to and from the IC card; 

a computers coupled to the card reader, to implement at 
least one appUcation to enable a user to access and 
manage select resources of the plurality of resources of 
the IC card; and 

an application-independent application interface execut- 
ing on the computer to implement services utilized by 
the computer-implemented application to facilitate user 
access to certain of the plurality of resources provided 
by the IC card. 

2. A system as recited in claim 1, wherein the application- 
independent application interface supports configuration 
services which permit a user to reconfigure the IC card. 

3. A system as recited in claim 1, wherein the application- 
independent application interface supports resource man- 
agement services which permit a user to manage the 
resources provided by the I C card. 
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4. A system as recited in claim 1, further comprising: 
an operating system executing on the computer, the 

application being run on the operating system; and 
the application-independent application interface is 
implemented as a service layer for the operating system ^ 
and is securely integrated with the operating system, 

5. A system as recited in claim 1, wherein the IC card is 
a smart card. 

6. A system as recited in claim 1, wherein: 

the IC card has a memory to store at least one asset 
indicative of value; and 

the application-independent application interface is con- 
figured to retrieve the asset from the IC card for use by 
the application. 15 

7. A system as recited in claim 1, wherein the IC card 
comprises: 

a memory to store at least one cryptographic key; and 
a processor configured to perform a cryptographic func- 
tion using the cryptographic key stored in the memory. 20 

8. A system as recited in claim 1, wherein the IC card 
comprises: 

a memory to store at least one certificate; and 
a processor configured to supply the certificate to the 
application- independent application interface. 

9. A system as recited in claim 1, wherein: 

the IC card has a memory to store at least one crypto- 
graphic key and a processor to provide cryptographic 
functionality using the cryptographic key; 3Q 

the application requests a cryptographic function involv- 
ing use of the cryptographic key stored on the IC card; 
and 

the application-independent application interface com- 
prises: 35 
a cryptographic application program interface (CAPI) 
to interface with the application and handle the 
application's request for the cryptographic function; 
and 

a cryptography service provider (CSP) independent 40 
from, but dynamically accessible by, the CAPI, the 
CSP providing the cryptographic function requested 
by the application, the CSP managing access to the 
IC card for use of the cryptographic key in support 
of the cryptographic function while protecting the 45 
cryptographic key stored on the IC card to prevent 
exposure of the cryptographic key to the CAPI and 
the application. 

10. A system as recited in claim 9, wherein the processor 

of the IC card is configured to perform a cryptographic 50 
function selected from a group of cryptographic functions 
comprising (1) encryption using the cryptographic key, (2) 
decryption using the cryptographic key, (3) digital signing 
using the cryptographic key, (4) verifying authentication of 
a digital signature using the cryptographic key, (5) genera- 55 
tion of the cryptographic key, and (6) destruction of the 
cryptographic key. 

11. A system as recited in claim 1, wherein the 
application-independent application interface is configured 

to support at least one request made by the application for a 60 
particular resource provided by the IC card, said at least one 
request being selected from a group of requests comprising 
(1) initializing the IC card to an initial state, (2) retrieving 
characteristics of the IC card, (3) retrieving an identification 
of the IC card, (4) logging into the IC card, (5) logging out 65 
of the IC card, and (6) changing a passcode for access to the 
IC card. 
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12. A system as recited in claim 1, wherein the 
application-independent application interface is configured 
to support at least one request made by the application for a 
particular resource provided by the IC card, said at least one 
request being selected from a group of requests comprising 
(1) generating a cryptographic key for the IC card, (2) 
retrieving a public cryptographic key from the IC card, (3) 
adding a certificate or other data resource to the IC card, (4) 
retrieving a certificate or other data resource from the IC 
card, and (5) deleting a certificate from the IC card. 

13. A system as recited in claim 1, wherein the 
apphcation-independent application interface is configured 
to support at least one request made by the application for a 
particular resource provided by the IC card, said at least one 
request being selected from a group of requests comprising 
(1) signing data supplied by the application, (2) encrypting 
data supplied by the application, (3) decrypting data sup- 
plied by the application, and (4) verifying a signature 
supplied by the application. 

14. A system as recited in claim 1, wherein: 
the application requests digital signing of data; 

the application -independent application interface hashes 
the data to produce a hash and passes the hash to the IC 
card; and 

the IC card digitally signs the hash using a cryptographic 
signing key and returns the signed hash to the 
application-independent application interface without 
exposing the cryptographic signing key. 

15. A system as recited in claim 1, wherein: 

the application requests verification of a digital signature; 

the application-independent application interface passes 
the digital signature to the IC card; and 

the IC card verifies the digital signature using a crypto- 
graphic key and informs the application-independent 
application interface as to whether the digital signature 
is authentic. 

16. A system as recited in claim 1, wherein: 
the application requests encryption of data; 

the application interface passes at least a portion of the 
data to the IC card; and 

the IC card encrypts the data passed from the application 
interface using an encryption key and returns the 
encrypted data to the application interface. 

17. A system as recited in claim 1, wherein: 

the application requests decryption of encrypted data; 
the application interface passes the encrypted data to the 
IC card; and 

the IC card decrypts the encrypted data using a decryption 
key and returns decrypted data to the application inter- 
face. 

18. A computer- implemented application program inter- 
face to interface an application executing on a computer 
operating system with a program executing on an integrated 
circuit (IC) card, the IC card being coupled to communicate 
with a computer on which the operating system is running, 
the application program interface comprising: 

a cryptographic services module which implements cryp- 
tographic functionality for the application, the crypto- 
graphic services module using cryptographic resources 
maintained on the IC card so that when the application 
requests a cryptographic function, the cryptographic 
services module communicates with the IC card to have 
the IC card support the cryptographic function without 
exposing the cryptographic resources maintained 
thereon; and 
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a card management services module which implements 
administration functionality for the application for 
managing resources maintained on the IC card so that 
when the application requests that an administrative 
task be performed on the IC card, the card management 5 
services module communicates with the IC card to 
perform the administrative task requested by the appli- 
cation. 

19. A computer-implemented application program inter- 
face as recited in claim 18, wherein the cryptographic 
function is selected from a group comprising encryption, 
decryption, digital signing, and verification. 

20. A computer-inaplemented application program inter- 
face as recited in claim 18, wherein the administrative task 
is selected from a group comprising initialization of the IC 
card, cryptographic key generation, passcode configuration, 
management of cryptographic keys on the IC card, manage- 
ment of certificates on the IC card, and management of 
assets on the IC card. 

21. A computer-implemented application program inter- 
face as recited in claim 18, wherein the cryptographic 
services module comprises: 

a cryptographic application program interface (CAPI) to 
interface with the application and handle the applica- 
tion's request for the cryptographic function; and 25 

a cryptography service provider (CSP) independent from, 
but dynamically accessible by, the CAPI, the CSP 
performing the cryptographic function requested by the 
application by accessing the IC card for support of the 
cryptographic function while protecting the crypto- 30 
graphic resources on the IC card to prevent exposure of 
the cryptographic resources to the CAPI and the appli- 
cation. 

22. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 35 
modules is configured to support at least one request made 
by the application which is selected from a group of requests 
comprising (1) initializing the IC card to an initial state, (2) 
retrieving characteristics of the IC card, (3) retrieving an 
identification of the IC card, (4) logging into the I C card, (5) 40 
logging out of the IC card, and (6) changing a passcode for 
access to the IC card. 

23. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 
modules is configured to support at least one request made 45 
by the application which is selected from a group of requests 
comprising (1) generating a cryptographic key for the IC 
card, (2) retrieving a public cryptographic key from the IC 
card, (3) adding a certificate or other data resource to the IC 
card, (4) retrieving a certificate or other data resource from 50 
the IC card, and (5) deleting a certificate from the IC card. 

24. A computer-implemented application program inter- 
face as recited in claim 18, wherein at least one of the service 
modules is configured to support at least one request made 
by the application which is selected from a group of requests 55 
comprising (1) signing data supplied by the application, (2) 
encrypting data supplied by the application, (3) decrypting 
data supplied by the application, and (4) verifying a signa- 
ture supplied by the application. 

25. A computer readable memory comprising a computer- 50 
implemented application program interface as recited in 
claim 18. 

26. A computer to configure and manage a plurality of 
resources of an integrated circuit (IC) card, the computer 
comprising: ^5 

a processor; 
a display; and 
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a card manager user interface (UI) executing on the 
processor, the card manager UI presenting at least one 
graphical dialog screen on the display which enables a 
user to reconfigure the IC card and to manage the 
resources on the IC card. 

27. A computer as recited in claim 26, wherein the card 
manager UI has icons representing resources on the IC card. 

28. A computer as recited in claim 27, wherein the card 
manager UI enables a user to add and delete resources by 
manipulating the icons presented on the graphical dialog 
screen. 

29. A computer as recited in claim 26, wherein: 

the card manager UI presents a resource list of available 
resources that can be placed on the IC card; and 

the card manager UI enables the user to add resources 
from the resource list to the IC card and to remove 
resources firom the IC card to the resource Ust. 

30. Aconfiguration system enabling a user to configure an 
integrated circuit (IC) card after manufacture of the IC card, 
the IC card having a processor and programmable memory, 
the configuration system comprising: 

a computer having a card reader to interface with the IC 
card; and 

a card management application interface executing on the 
computer to enable the user to access the IC card and 
add, delete and otherwise configure the resources of the 
IC card stored within the programmable memory with 
data selected by a user. 

31. Aconfiguration system as recited in claim 30, wherein 
the card management application interface permits a user to 
manage resources on the IC card. 

32. Aconfiguration system as recited in claim 30, fiiirther 
comprising a graphical user interface executing on the 
computer to present graphical representations of resources 
that are available on the I C card. 

33. An integrated circuit (IC) card comprising: 
a processor; 

a data I/O port controlled by the processor to receive and 
output data; 

a data memory coupled to the processor, the data memory 
being partitioned into a public storage and a private 
storage; 

the processor being configured to access the private 
storage of the data memory only following receipt and 
verification of an externally supplied passcode from the 
data I/O port; and 

the processor being configured to access the public stor- 
age and output contents stored in the public storage to 
the data I/O port without requiring receipt and verifi- 
cation of the passcode. 

34. An integrated circuit (IQ card as recited in claim 33, 
wherein the private storage stores at least one cryptographic 
key. 

35. An integrated circuit (IQ card as recited in claim 33, 
wherein the private storage stores at least one public key 
certificate. 

36. An integrated circuit (IQ card as recited in claim 33, 
wherein the private storage includes a permanent memory 
location to permanently store at least one private crypto- 
graphic key. 

37. An integrated circuit (IQ card as recited in claim 33, 
wherein the private storage stores electronic assets indica- 
tive of commercial value. 

38. An integrated circuit (IQ card as recited in claim 33, 
wherein the IC card is uniquely assigned to a user, and the 
public storage stores non-confidential information pertain- 
ing to the user. 
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39. A method to provide cryptographic function support to 
a requesting application, the method comprising the follow- 
ing steps: 

storing at least one cryptographic key on a portable 
integrated circuit (IC) card; 5 

supplying a request for a cryptographic function from the 
application to an application-independent application 
interface; 

establishing data communication between the application- 
independent application interface and the IC card; and 

performing the cryptographic function requested by the 
application cooperatively between the application- 
independent application interface and the IC card using 
the cryptographic key stored on the IC card and without 15 
exposing the cryptographic key from the IC card. 

40. A method as recited in claim 39, wherein the per- 
forming step comprises the cryptographic function is 
selected from a group comprising encryption, decryption, 
digital signing, and verification. 20 

41. A method as recited in claim 39, wherein the per- 
forming step comprises digitally signing data according to 
the following steps: 

hashing the data at the aplication-independent application 
interface to produce a hash; 25 

passing the hash from the application-independent appli- 
cation interface to the IC card; 

digitally signing the hash using a cryptographic signing 
key; and 

passing the signed hash from the IC card back to the 
application independent application interface without 
exposing the cryptographic signing key. 

42. A method as recited in claim 39, wherein the per- 
forming step comprises verifying a digital signature accord- 
ing to the following steps: 

passing the digital signature form the application- 
independent application interface to the IC card; 

verifying the digital signature using the cryptographic 
key; and 40 

informing the application-independent application inter- 
face as to whether the digital signature is authentic. 

43. A method as recited in claim 39, wherein the per- 
forming step comprises encrypting data according to the 
following steps: 45 

passing at least a portion of the data from the application- 
independent application interface to the IC card; 

encrypting, at the IC card, the data passed from the 
apphcation- independent application interface using the 
cryptographic key; and 

passing the encrypted data from the IC card back to the 
application- independent apphcation interface. 

44. A method as recited in claim 39, wherein the per- 
forming step comprises decrypting data according to the 
following steps: 

passing at least a portion of encrypted data from the 
application-independent application interface to the IC 
card; 

decrypting, at the IC card, the encrypted data passed from go 
the application-independent application interface using 
the cryptographic key; and 

passing the decrypted data from the IC card back to the 
application- independent application interface. 

45. A method as recited in claim 39, further comprising 65 
verifying the authenticity of the application-independent 
application interface amd the OC card to each other. 
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46. A method as recited in claim 39, further comprising: 
supplying the request for a cryptographic function from 

the application to a cryptographic application program 
interface (CAPI); 

selecting a cryptography service provider (CSP) to per- 
form the requested cryptographic function; 

establishing data communication between the CAPI and 
the CSP; 

establishing data communication between the CSP and 
the IC card; and 

performing the cryptographic function cooperatively 
between the CSP and the IC card using the crypto- 
graphic key stored on the IC card without exposing the 
cryptographic key from the IC card. 

47. A method as recited in claim 46, further comprising: 
verifying authenticity of the CSP to the CAPI. 

48. A method as recited in claim 46, further comprising: 
verifying authenticity of the CSP and the IC card to each 

other. 

49. A method for personalizing contents on an integrated 
circuit (IQ card from a computer according to a user's 
preferences, the method comprising the following steps: 

interfacing the IC card to the computer with an 
apphcation-independent apphcation interface execut- 
ing on the computer; 

presenting a user interface on the computer to the user as 
part of the execution of the application interface; 

initializing the IC card using the user interface; 

configuring the IC card, using the user interface, to 
include cryptographic resources and non-cryptographic 
resources; and 

managing the cryptographic and non-cryptographic 
resources that are maintained on the IC card using the 
user interface. 

50. A method as recited in claim 49, wherein the manag- 
ing step comprises adding resources to, and removing 
resources from, the IC card. 

51. A method as recited in claim 49, further comprising 
the following steps: 

partitioning a memory on the IC card into a private 
storage and a public storage; and 

the configuring step comprises storing some of the 
resources in the private storage and some of the 
resources in the public storage, and establishing a 
passcode for use in accessing the private storage. 

52. A method for conducting secure electronic transac- 
tions comprising the following steps: 

configuring, at a first computing site, a portable multi- 
purpose integrated circuit (IC) card with resources that 
enable the IC card to be used for multiple purposes, the 
resources including a cryptographic key and a certifi- 
cate which can be used for at least one of the multiple 
purposes; 

transporting the multi-purpose IC card firom the first 
computing site to a second computing site; 

interfacing the multi-purpose IC card with an application 
interface executing at the second computing site, the 
application interface supporting an application which is 
executing at the second computing site to process data 
for a designated purpose, the apphcation requiring 
transformation of at least a portion of the data accord- 
ing to a cryptographic function, the application having 
a certificate; 

exchanging certificates between the application and the IC 
card to verify authenticity to each other; 
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establishing data communication between the application 
and the IC card through the application interface; 

supplying a request for the cryptographic function from 
the application to the application interface; 

performing the cryptographic function cooperatively 
between the application interface and the IC card using 
the cryptographic key stored on the IC card without 
exposing the cryptographic key from the IC card; 

transporting the IC card from the second computing site 
to a third computing site; 

interfacing the IC card with an application interface 
executing at the third computing site, the application 
interface at the third computing site supporting an 
application which is executing at the third computing 
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site and requires access to a non-cryptographic resource 
on the IC card for another designated purpose; 
establishing data communication between the apphcation 
and the IC card through the application interface; 

making a request from the application for the non- 
cryptographic resource on the IC card; and 

fulfilling the request for the non-cryptographic resource. 

53. A method as recited in claim 52 wherein the applica- 
tion at the third computing site requests access to an asset 
maintained on the IC card and the fulfilhng step comprises 
supplying the asset from the IC card to the application at the 
third computing site. 

***** 
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